home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20030409-20031118
/
000023_fdc@columbia.edu_Mon Apr 28 10:21:34 EDT 2003.msg
< prev
next >
Wrap
Text File
|
2003-11-18
|
5KB
|
97 lines
Article: 14239 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.misc,comp.protocols.kermit.misc
Subject: Re: Communication protocol for direct serial link (null-modem or similar)?
Date: 28 Apr 2003 10:17:04 -0400
Organization: Columbia University
Lines: 80
Message-ID: <b8jd50$4fr$1@watsol.cc.columbia.edu>
References: <3R6qa.6946$b71.104830@news4.e.nsc.no> <b8bdvn$iun$1@watsol.cc.columbia.edu> <n05ra.7849$8g5.113401@news2.e.nsc.no>
NNTP-Posting-Host: watsol.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1051539425 12588 128.59.39.139 (28 Apr 2003 14:17:05 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 28 Apr 2003 14:17:05 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.misc:9759 comp.protocols.kermit.misc:14239
In article <n05ra.7849$8g5.113401@news2.e.nsc.no>,
Toralf Lund <toralf-delete-this@procaptura.com> wrote:
: On Fri, 25 Apr 2003 15:42:15 +0200, Frank da Cruz wrote:
: > In article <3R6qa.6946$b71.104830@news4.e.nsc.no>, Toralf Lund
: > <toralf-delete-this@procaptura.com> wrote:
: > : I'm looking for a protocol that may be used for simple communication
: > : across a direct serial link - RS232 using null-modem cable or similar
: > : - between a Linux host and a simple (old) IPC (Intelligent Peripheral
: > : Controller) board.
: > :
: > : The IPC has no real OS, just a simple, custom kernel, and rather
: > : limited development support, so the protocol needs to be simple to
: > : implement. Also, the system is really low-end by today's standards -
: > : it's has a 12.5Mhz MC68010 CPU and 1Mb RAM - so the runtime must be
: > : fairly small and efficient.
: > :
: > : The link will be used only to send simple packets ("commands") to the
: > : IPC, and status from the IPC back to the Linux system; there will be
: > : no file transfers or anything.
: > :
: > : Protocols I've considered:
: > : - Kermit
: > : - AHDLC/LAPB (as utilised e.g. by PPP) - X/Y/Z-modem
: > :
: > : What would you people out there recommend choosing? And does anyone
: > : know of any good example source code that may help me get started? I'm
: > : primarily interested in a nice and isolated implementation of the
: > : packet communication itself, i.e. source code without all the
: > : additional bits normally found in comms packages, like UI operations,
: > : file I/O, modem dial etc., which I don't need (and I don't want them
: > : there to confuse everything.)
: > :
: > Embedded Kermit is exactly like that, except it's for transferring
: > files, not sending simple messages:
: >
: > http://www.columbia.edu/kermit/ek.html
: >
: > If you treat a message as a file, then Kermit would be fine.
: How would I do that? What does the "file" interface look like?
:
A file is whatever you want it to be. From Kermit's point of view, it is
an ordered series of bytes that has a name. A message does not normally have
a name, but otherwise it's the same as a file as far as Kermit is concerned.
When Kermit sends a file, it breaks it up into packets that have a certain
maximum length. Thus if the file is longer than a packet, multiple packets
must be sent, and therefore packets must have sequence numbers.
Packets can be lost or damaged in transit; therefore they must have checksums
or CRCs so errors can be detected.
Packets must be framed so the packet reader can identify the beginning and
end as well as control fields such as the sequence number and checksum.
When errors are detected, the packet receiver must have a way of notifying
the packet sender so the same packet can be retransmitted; thus packets are
acknowledged or negatively acknowledged.
All this is necessary no matter whether you are sending a message or a file,
and all of it is already done by Kermit.
The suitability of this model to the IPC (send command, get status back)
depends on what you mean by "status". If it's simply an indication of success
or failure, this is handled within the Kermit protocol by the Acknowledgement
to the Z (end-of-file) packet, which can contain a status indicator.
If the return status is something more complicated, it can be sent back as
a file in the reverse direction.
You get a slight amount of extra overhead because Kermit is designed to send
not just one file, but any number of them, in a single session. Thus there
is the per-session overhead (begin and end packet) and the per-file overhead
((begin packet, attribute packet, and end packet). Then for each file, zero
or more data packets.
So while this might not seem ideal for a simple command-and-status protocol,
it's already done. E-Kermit should be easily adaptable to the IPC, and
Kermit software is already available for Windows, Unix, etc etc.
- Frank